![AWS再入門ブログリレー Amazon DocumentDB編](https://devio2023-media.developers.io/wp-content/uploads/2019/05/amazon-documentdb.png)
AWS再入門ブログリレー Amazon DocumentDB編
はじめに 本ブログリレーについて
当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2019』の4日目のエントリです。昨日はKitano Yuichiによる「Amazon SES」でございました。
このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
AWSをこれから学ぼう!という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2019年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。
では、さっそくいってみましょう。本日のテーマは『Amazon DocumentDB』です。
目次
Amazon DocumentDBとは
高速でスケーラブルかつ高可用性な完全マネージド型のMongoDB互換ドキュメントデータベースサービスです。
と、これだけ聞いても¯\_(ツ)_/¯
って感じですよね。各要素について、もう少し詳細に説明します。
ドキュメント(指向)データベース
RDBでいうところの各レコード(ドキュメントデータベースではドキュメントと言います)にJSONライクなデータを格納するデータベースのことを指します。 RDBでいうテーブル(ドキュメントデータベースではコレクションと言います)の各レコード(ドキュメント)のJSONの構造は同じである必要はありません。またレコード(ドキュメント)を更新する際も、元と同じ構造を維持する必要もなく、新しい要素(フィールドと言います)を追加したり、逆に削除したりしても構いません。RDBのように厳密にスキーマを管理する必要がないので、より柔軟に利用することができます。
(補足:ややこしいのでRDBとの用語対応表を貼っておきます)
RDB | ドキュメントデータベース(MongoDB) |
---|---|
データベース | データベース |
テーブル | コレクション |
行(レコード) | ドキュメント |
列(カラム) | フィールド |
PK(プライマリキー) | ObjectId |
※ DocumentDB開発者ガイドより引用(一部追加、抜粋)
例:ふたつのドキュメントが格納されていますが、その構造は同じではありません
{ "_id" : ObjectId("5d18760d11a12c05cac220e1"), "name" : "kazue", "age" : 32, "like" : [ "music", "soccer" ] } { "_id" : ObjectId("5d18765911a12c05cac220e2"), "name" : "yamada", "age" : 25, "job" : "sales", "birthplace" : "Osaka" }
例:各ドキュメントは要素(フィールド)を自由に追加、削除できます
{ "_id" : ObjectId("5d18760d11a12c05cac220e1"), "name" : "kazue", "age" : 32, "like" : [ "music", "soccer" ] }
↓ "age"
削除、 "blood-type"
追加↓
{ "_id" : ObjectId("5d18760d11a12c05cac220e1"), "name" : "kazue", "like" : [ "music", "soccer" ], "blood-type" : "b" }
MongoDB互換
MongoDBはドキュメント指向データベースの中で最もメジャーな製品です。 DocumentDBはMongoDB(MongoDB Community Edition3.6)との互換性があるので、各言語に存在するMongoDBを扱うためのSDKやライブラリがそのまま使用できます。 また、AWS DMS(AWS Database Migration Service)を使ってEC2上で稼働しているMongoDBを容易にDocumentDBに移行することもできます。
高速&スケーラブル
データ読み込みに関しては、リードレプリカを最大15台まで増やしていくことができ、最大秒間100万リクエストが実行可能になります。 一方データ書き込みに関しては、プライマリインスタンスのメモリ容量を数分以内にスケールアップすることができます。最大メモリ容量は768GBです。 また、今回は説明を割愛しますが、ストレージレイヤがAuroraと同様のアーキテクチャになっており、非常に高速に動作します。かつ、ストレージは自動拡張します。そのためストレージのサイジングを行う必要がありません。ストレージは最大64TBまで拡張可能です。
高可用性
- 99.99% の可用性を備えるように設計されています。
- インスタンスに障害が発生した場合、自動的にインスタンスと関連プロセスを再起動します。インスタンスの再起動時間は通常 30 秒以下です。
- さらに、インスタンス再起動後もキャッシュをそのまま保持します。
- マスターインスタンスに障害が発生した場合、リードレプリカを作成している場合はいずれかのリードレプリカに自動的にフェイルオーバーします。
- ストレージボリュームは3AZに、かつ各AZで2箇所ずつ、つまり2×3=6箇所にレプリケートされます。データベースの書き込み性能に影響を与えることなく最大 2 つ、読み込み性能に影響を与えることなく最大 3 つのデータコピーの損失を透過的に処理します。
- スナップショットは自動でS3に保存されます。S3の耐久性は99.999999999%です。
DocumentDBのメリット
JSONのまま、かつスキーマレスにデータ格納できる、というのが最大のメリットかと思います。
ひとつ目、JSONのままデータ格納できるという点について。フロントエンド⇆バックエンドの連携時に、データをJSON型にしてやりとりするというのは昨今よくある構成です。ここでバックエンドから操作するデータベースとして、RDBを採用することを想定してみましょう。 フロント⇆バックエンド間のやりとりはJSONを介して行われます。一方、バックエンド⇆DBのやりとりはSQLを介してですね。間にOR Mapperも利用するかもしれません。いずれにせよデータ格納処理では、JSONデータをアプリケーション内でリレーショナルなテーブルの形に変換してからデータ格納する必要があります。特に、ネストした構造のJSONを変換するのは面倒な作業になるでしょう。 逆のデータ参照も然りで、リレーショナルなテーブルのデータをJSONに変換してクライアントに渡す必要があります。 DocumentDBをはじめとするドキュメント指向データベースを使う場合、DBに格納するデータ型はJSON(ライク)なままで良いので、データ型の変換処理をアプリケーション層でゴリゴリ書く必要性は減るでしょう。これがJSONのままデータ格納できるというメリットです。
続いてふたつ目のメリット、スキーマレスについてです。 テーブル(コレクション)単位でスキーマを定義する必要はなく、行(ドキュメント)ごとに別々のスキーマを持てるので、扱うデータの形を決めきれない時にDocumentDBは便利です。 そういう意味で、要件が変化していくアジャイル的な開発現場ではより有用なデータベースと言えるでしょう。
DocumentDBのユースケース
Webアプリケーションのバックエンドとして
前述の通り、JSONでデータ連携することが多い昨今のWebアプリケーションにおいて、JSONのままデータ格納できるというのは大きなアドバンテージです。その中でもスキーマレスな以下のようなデータを扱う際に特に役立つでしょう。
- ユーザーのプロフィールデータ(ユーザーごとに保存したい情報が異なる)
- ECサイトの商品情報(異なる種類の商品の場合は記載項目を変えたい)
- CMS(どんな項目が必要かは個々のコンテンツ次第)
すでにEC2上でMongoDBを利用している
こういった場合はぜひDocumentDBを利用されることをご検討された方が良いでしょう。 DocumentDBはマネージドサービスですので、煩わしい管理業務をAWSに任せてアプリケーション最適化に集中できます。
他DBとの使い分け
DocumentDB(MongoDB)とRDS・DynamoDB間との位置付けは、以下の弊社菊池のスライドがわかりやすいと思います。
RDSとの使い分け
トランザクション処理が求められるケースではRDSを使うのが良いでしょう。DocumentDBは現在トランザクション処理をサポートしておりません。(MongoDBでは4.0でトランザクションがサポートされましたがあくまで補助的なもの。そしてDocumentDBはMongoDB3.6互換です)
また、かっちりスキーマを決められるデータを扱う場合もRDSを使う方がシンプルで良いでしょう。DocumentDBの良さを活かすことができません。またDocumentDBの場合各レコード(コレクション)ごとにスキーマ情報も持つ必要があるため、RDSよりデータ量が大きくなりがちです。
DynamoDBとの使い分け
スケーリング性能でいえばDynamoDBの方が高いです。DocumentDBの優位性は柔軟にクエリが書ける点にあります。ですのでアクセスパターンが複数ある、もしくは読み切れない場合にはDocumentDBの方が便利です。またネストしたJSONのフィールドにもインデックスを貼ることができる、というのもDocumentDBの強みです。
やってみよう
開発者ガイドに開始方法についてのページがありますので、こちらを参考に一度クラスターの作成からmongoシェルを介してのデータ操作を試してみてください。
こちらのガイドで紹介されているデータ操作は、挿入、検索、更新、削除のみですが、以下のページにそれ以外の操作方法についてもまとめられています。余力があればこれらの操作もお試しください。
Amazon DocumentDB 開発者ガイド ドキュメントでの作業
DocumentDBは決してお安いサービスではないので、お試しになられたあとはクラスターを削除することをお勧めいたします。継続的にお試しされるのであれば、以下エントリを参考に一時停止&再開をご検討ください。
まとめ
DocumentDBについてご紹介しました。私は先日AWS Summit Tokyo、AWS Summit Osakaに参加した際、AWSのデータベース系サービスをまとめて紹介するセッションを聴講しました。その中でスピーカーのAWSの方が引用されていたのは「万能なデータベースは存在しない」という amazon.com CTOの Werner Vogelsさんの言葉です。それぞれのサービスの特性を理解して、適材適所で利用することが肝要です。本エントリにてDocumentDBの特性を理解いただき、データベース選定の際にDocumentDBを選択肢の一つに加えていただければ幸いです。
参考情報
- AWS Black Belt Online Seminar
- YouTube
- SlideShare
- 開発者ガイド
- Amazon DocumentDB
- [JAWS DAYS 2019] 「Amazon DocumentDB(with MongoDB Compatibility)入門」について話しました #jawsug #jawsdays #jd2019_d
再入門シリーズ 明日(7/5)は
もきゅりんの「AWS Step Functions」編です。お楽しみに!!